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(54) Modular application collaboration 

(57) A modular application collaborator for providing 
inter-operability between applications including a plural- 
ity of connectors for communicating with a like plurality 
of applications and an interchange server. The inter- 
change server includes an application collaboration 
module and a service module. The service module 
transfers messages between connectors and the appli- 



cation collaboration module. The application collabora- 
tion module defining the inter-operability between two 
or more applications and includes a trigger and a trans- 
action responsive to the trigger. The trigger is activated 
upon receipt of data from one or more connectors re-, 
suiting in the transaction delivering data to one or more 
connectors for transfer to an associated application. 
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Des ription 

Background 

The present invention relates generally to comput- 
ing systems, and more particularly to a method and ap- 
paratus for providing collaboration between applications 
operating in an information system. 

Corporations have spent billions of dollars a year to 
implement custom, standalone information systems that 
address specific business domain functionality require- 
ments such as accounting, payroll, manufacturing, and 
distribution. By creating these separate, standalone 
systems, each individual section of the business proc- 
ess became isolated from the others. 

Overtime, Corporate Information Technology (CIT) 
departments began shifting away from in-house devel- 
opment of these custom systems and have attempted 
to minimize costs by purchasing enterprise applications 
on the outside. Enterprise applications are more gener- 
ic, providing general business functionality in a prepack- 
aged product. Typically, enterprise applications include 
heterogeneous combinations of application systems, 
hardware platforms, operating systems, third- and 
fourth-generation languages, databases, network pro- 
tocols, and management tools. While these applications 
bring tremendous benefits to the companies that imple- 
ment them, on an enterprise level, they only exacerbate 
the proliferation of "process islands" because they are 
not readily integratable. 

Stand-alone enterprise applications provide power- 
ful tools for handling many business processes. How- 
ever, some functionality is often duplicated in separate 
applications, driving up the cost when bundling enter- 
prise applications. Custom functional integration be- 
tween enterprise applications, while desirable, is gener- 
ally cost prohibitive, and defeats the benefits of the 
make-versus-buy decision to purchase the enterprise 
application in the first place. Tool and middleware ven- 
dors offer solutions for data integration, but not function 
integration, and even those solutions require significant 
custom coding to implement. 

Summary of the Invention 

In general, in one aspect, the invention provides a 
modular application collaborator for providing interop- 
erability between applications including a plurality of 
connectors for communicating with a like plurality of ap- 
plications and an interchange server. The interchange 
server includes an application collaboration module and 
service module. The service module transfers messag- 
s between connectors and the application collabora- 
tion module. The application collaboration defining the 
inter-operability between" two or more applications and 
includes a trigger and a transaction responsive to the 
trigger. The trigger is activated upon receipt of data from 
one or more connectors r suiting in the transaction de- 



livering data to one or more connectors for transfer to 
an associated application. 

Aspects of the invention include the following fea- 
tures. The interchange server service module includes 
5 a transaction service and an error service. The transac- 
tion in the application collaboration module includes one 
or more actions and the transaction service records 
each action and a compensating action for undoing an 
associated action. The error service monitors for errors 

to in the interchange server, and, upon detection of an er- 
ror, stops the execution of a transaction and triggers the 
execution of any required compensating actions to undo 
the interrupted transaction. 

Each connector includes an application interface, a 

15 business module and interchange server interface. The 
application interface includes an API manipulator for re- 
ceiving and transferring data and methods between a 
connector and its associated application. The business 
module includes business methods and transforms for 

20 manipulating data for transfer between an associated 
application and an application collaboration module. 
The interchange server interface for transferring data 
and methods between a connector and an application 
collaboration module. 

25 a transaction includes a finite state machine. Data 

transfers between connectors and an application collab- 
oration module are by objects transferred by the service 
module in the interchange server. The service module 
includes an event service having subscription and pub- 

30 lication services. An application collaboration module 
subscribes to one or more connectors based on the trig- 
ger. The connectors publish data to the event service 
upon receipt of trigger data from its associated applica- 
tion resulting in the publication service delivering theda- 

35 ta to the application collaboration module. The inter- 
change server further includes RAS services and mes- 
saging services for assuring delivery of messages to in- 
terchange server components. 

In another aspect, the invention provides a modular 

*o application collaborator for collaborating applications 
implementing distinct functions including an inter- 
change server and first and second application connec- 
tors. Each connector for transferring data between the 
interchange server and an associated application. The 

45 interchange server including an application collabora- 
tion module and a service module. The service module 
lor transferring objects between the first and second 
connectors and the application collaboration module. 
The application collaboration module defining the inter- 
so operability between the first and second applications 
and including a trigger and a transaction responsive to 
the trigger. The trigger being activated upon receipt of 
data from a first one of the first and second conn ctors, 
and the transaction delivering data to a second one of 

55 the first and second connectors for transfer to an asso- 
ciated application. 

In another aspect, the invention provides a method 
for providing inter-operability between applications op- 
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erating on different processes including defining an in- 
ter-operability (unction between a first and second ap- 
plication. The inter-operabiiity function is divided into 
generic and vendor specific sub-pieces. A application 
collaboration module for storing and executing the ge- s 
neric sub-piece of the inter-operability function is creat- 
ed. Two application specific connectors (or storing and 
executing the vendor specific sub-pieces of the inter- 
operability function associated with the first and second 
applications are created. Finally, the application cotlab- io 
oration module and two application specific connectors 
are linked to achieve the inter-operability function. 

One advantage of the invention is that it allows busi- 
nesses to significantly improve efficiency and productiv- 
ity by integrating related functionality, is 

Other advantages are: providing a single packaged 
product to integrate any application to any other appli- 
cation, independent o( platform, operating system, and 
network: permitting enterprise applications in different 
functional areas to operate as an integrated suite, shar- 20 
ing functions and program logic; integrating process is- 
lands at a level that supports implementation of a col- 
laborative business model; permitting easy installation 
and removal of enterprise applications; and operation 
across multiple versions of participating applications. 2s 
thereby providing a flexible long-term solution to inte- 
grating applications and eliminating the high mainte- 
nance costs of custom integration and upgrading ver- 
sions ol applications. 

Other advantages and features will be apparent 30 
from the following description and claims. 

Brief Description of the Drawings 

Figure 1 is a schematic block diagram of a modular 35 
application collaborator according to one embodiment 
of the present invention. 

Figure 2 is a flow diagram for a simplified collabo- 
ration according to one embodiment of the present in- 
vention.. 40 

Figure 3 is a schematic block diagram of an inter- 
change server according to one embodiment of the 
present invention. 

Figure 4 is flow diagram (or a event publication and 
subscription service according to one embodiment of 4 5 
the present invention. 

Figure 5 is flow diagram for transaction service ac- 
cording to one embodiment of the present invention. 

Figure 6 is flow diagram (or an interchange server 
according to one embodiment of the present invention, so 

Figure 7 is a flow diagram for a service request per- 
formed by an interchange server according to one em- 
bodiment of the present invention. 

Figure 8 is a flow diagram for a shutdown procedure 
for an interchange server according to one embodiment 55 
of the present invention. 

Figure 9 is a schematic block diagram o( an appli- 
cation collaboration module according to one embodi- 



ment of the present invention. 

Figure 10 is a schematic diagram showing ordered 
message flows for a simple application collaboration ac- 
cording to one embodiment of the present invention. 

Figure 1 1 is flow diagram for creating an application 
collaboration according to one embodiment of the 
present invention. 

Figure 12 is a flow diagram for an application col- 
laboration according to one embodiment of the present 
invention. 

Figure 13 is a schematic block diagram of a con- 
nector according to one embodiment of the present in- 
vention. 

Figure 1 4 is a flow diagram for a connector accord- 
ing to one embodiment of the present invention. 

Figure 15 is a schematic block diagram of an ad- 
ministrative tool according to one embodiment of the 
present invention. 

Figure 16 is a block diagram for a connector devel- 
opment kit according to one embodiment o( the present 
invention. 

Detailed Description 

Referring now to Figure 1, the architecture for a 
modular application collaborator 10 includes an inter- 
change server 20 having one or more connectors 30, 
and one or more application collaboration modules 40, 
administrative tools 50 and development tools 60. Cou- 
pled to each connector 30 is an application 70. 

Interchange server 20 is a distributed application 
server that provides an object oriented run-time platform 
for all components. 1 1 also provides mechanisms to man- 
age, configure and control components and provides all 
of the reliability, availability, and serviceability features 
(the RAS features) found in a typical server environ- 
ment. An object component can reside in any inter- 
change server within the same administrative domain. 
An administrative domain is a suite of interconnected 
connectors, application collaboration modules and in- 
terchange servers. Multiple cooperating interchange 
servers can run on different platforms. Platform in this 
case means any base software environment, including 
operating systems, databases (if necessary), and/or 
middleware. 

Connectors 30 enable applications to communicate 
with interchange server 20. Connectors 30 handle all the 
details of interfacing with applications 70, and provide 
an object-oriented interface to represent the application 
in tne interchange server's object and data model. Con- 
nectors 30 communicate with applications 70 and pro- 
vide a schema for interacting with other applications in 
the interchange server's object-oriented model. Con- 
nectors can be thought of as having two ends. An "in- 
terchange-end" is an object-oriented proxy schema for 
the application's data and methods. An "application- 
end" is a driver for th application's APIs. In other words, 
the connector's interchange-end presents a "virtual" ob- 



JSDOCID, <FP fW.S3?77A9 I > 



3 



5 



EP 0 853 277 A2 



6 



ject interlace to the interchange server for the data and 
methods (behavior) that reside in the application. To al- 
low application collaboration modules to be re-used 
across connectors, the virtual object interlace presented 
by the interchange-end of the connector is similar (or 
connectors having the same application class but which 
are produced by different vendors The application-end 
of a connector 30 is concerned with transferring infor- 
mation from application 70 to the virtual objects and with 
propagating changes (requests for change) made to the 
virtual objects back to application 70 The application- 
end of connector 30 also contains vendor specific logic 
required to manipulate the vendors APIs. Connectors 
are application and vendor-specific 

Application collaboration modules 40 provide the 
specific integration business logic and process flows re- 
quired to integrate two or more applications 70. Appli- 
cation collaboration modules uo contain the re-usable 
part of the integration business logic, whereas, the ap- 
plication specific piece of the participating business log- 
ic is stored in connectors 30 An application collabora- 
tion module 40 requires an interchange server 20 and 
an appropriate connector for each application 70 partic- 
ipating in a collaboration. Application collaboration mod- 
ules 40 are specialized objects that coordinate commu- 
nication and process flows between connector objects. 
Any application collaboration module 40 executing in 
the interchange server 20 will see only the interchange- 
end of any connector 30. Application collaboration ob- 
jects implement the business interactions in terms of 
message exchanges between the interchange server's 
services (which are objects), the participating applica- 
tion's connector objects and other application collabo- 
ration objects. 

Administrative tools 50 provide a set of toots and 
interfaces which allow end-user customers to install, 
configure, control and monitor interchange server 20 
and connectors 30. 

Development tools 60 provide a set of tools and li- 
braries that allow customers to develop their own appli- 
cation collaboration modules and connectors. Tools are 
driven from metadata in the interchange server's ob- 
jects. Metadata is a term used to describe the informa- 
tion which characterizes the data, and is sometimes re- 
ferred to as the data definition. 

Applications 70 include various business applica- 
tions supporting accounting, billing, customer service, 
payroll and other business processes. Application cli- 
ents interact with an associated application 70 using the 
application's user interface. Alternatively, applications 
70 may be non-business applications. Inter-operability 
between the applications 70 is defined in an application 
collaboration module 40. 

For example, a simplified business inter-operability 
function instituted in an first application collaboration 
module may require receiving data from a first applica- 
tion and writing a portion of it in a new format to a second 
application. A flow diagram for the simplified business 



inter-operability function is shown in Figure 2. Referring 
now to Figures 1 and 2, upon initialization, the first ap- 
plication collaboration module 40, and its associated 
(first and second) connectors 30 are installed in the in- 
5 terchange server 20 (100). The first application collab- 
oration module 40 provides a business inter-operability 
function that includes at least a trigger (e.g., the receipt 
of information from one or more applications) and a 
transaction (e.g., the writing of the new data to one or 
10 more applications) responsive to the trigger. The first ap- 
plication collaboration module 40 subscribes to an event 
based on the trigger for the particular business interop- 
erability function (102). In this example, the event is trig- 
gered by the receipt of information at a first connector 
15 associated with the first application (103). Based on in- 
formation received from the first application, the appli- 
cation-end of the associated connector passes data to 
the interchange-end of the first connector (104). The in- 
terchange-end of first connector transforms the informa- 
nt? tion into the interchange format object and publishes the 
event (receipt of the information or trigger) (105). The 
event is delivered in the form of an object generated by 
the first connector to the first application collaboration 
module that subscribed to the event (or to any applica- 
nt tion collaboration module that subscribed to the event 
or that requested the data) (1 06). 

Thereafter, the first application collaboration mod- 
ule executes its associated business inter-operability 
function and generates an object for transmission to the 
30 second connector (108)^ The object itself is delivered to 
the second connector (1 09), which in turn transforms the 
object (data and methods) into the appropriate format 
(by the interchange-end of the associated connector) 
and initiates the desired function in that connector's as- 
35 sociated application (by the application end of the con- 
nector) (HO). The details associated with the collabora- 
tion process will be described further below in associa- 
tion with the detailed descriptions for the individual com- 
ponents. 

40 

Interchange Server 

Referring now to Figure 3, an interchange server 
within a single administrative domain can be viewed as 

45 a bus into which various system components are 
plugged. Interchange server 20 includes application col- 
laboration module interlaces 200, connector interlaces 
202, external interfaces 203, a configuration tool inter- 
face 204 connected to configuration tool 205. set-up tool 

50 interlace 206 connected to set-up tool 207, system man- 
agement interlaces 209 and a plurality of service mod- 
ules 208. 

Configuration tool 205 allows a user to enable and/ 
or change application collaboration module and connec- 
55 tor properties. Setup tool 207 installs, removes and con- 
figures application connectors in an interchange server. 
System management interfaces 209 support industry 
standard (SMS/SNMP) administration interlaces and 



.icnrv^in. ^cr. #-.rr'j-T7">/?o 



7 



EP 0 853 277 A2 



e 



provide a management interfac to the interchange 
server's components. External interfaces 203 allow 
tools and other external agents to access and control 
objects within interchange server 20. 

Interchange server 20 is a component-oriented ob- 
ject execution environment for supporting the execution 
needs of application connectors 30 (Fig. 1 ) and applica- 
tion collaboration modules 40 (Fig. 1 ). It defines a base 
object model of objects and components, which function 
as targe grained container objects. Application connec- 
tors and collaborations are implemented in terms of this 
base model and are large grained containers within the 
interchange environment. This allows connectors and 
application collaboration modules to have powerful in- 
terfaces derived from the base model, while simultane- 
ously encapsulating the details of their implementation 
within that individual component of the interchange 
server. 

Components are large-grained objects which con- 
tain other objects and which can be loaded in via a DLL 
(dynamic linking and loading) at run-time. Objects and 
components are defined in terms of their interfaces 
which are strictly separated from their implementations. 
Components are named through a name service 230 
and found in a registry 232. 

Connectors are a component that acts as a proxy 
for an application. Connectors manage connector ob- 
jects (also called virtual objects) which are typically 
proxies for entities within the application. Application 
collaboration modules are objects which live in the in- 
terchange server and can be dynamically registered or 
de-registered. Application collaboration modules create 
or manage objects as needed. An application collabo- 
ration module can be viewed as a sub-component within 
interchange server 20 which uses the same base object 
model as the interchange server. Everything in the in- 
terchange server is expressed in terms of the base ob- 
ject model. The base object model defines objects and 
the mechanisms for describing them. The base object 
model'provides object orientation, distribution, location 
independence, and an ability to implement objects on 
the supported platforms. 

Objects interact via events and messages. Event 
subscription service 235, event publication service 236 
and messaging service 242 are the fundamental mech- 
anisms by which application collaboration objects inter- 
act with connector objects. The interchange server 20 
provides objects with "services". 

The services provided by service modules 208 in 
interchange server 20 are those required by the connec- 
tors and application collaboration modules to carry out 
their integration tasks. In one embodiment of the present 
invention, the services are depicted as modules on a 
bus and include name s rvice 230. registry service 232, 
event service 234 including subscription service 235 
and publication service 236, repository 238, dynamic 
loading service 240, messaging service 242, rules en- 
gine service 244, data transformation service 246. 



transaction service 248 and error and exception service 
260. The interchange server s rvices include the capa- 
bility to add and remove connectors and collaborations 
dynamically, to test new configurations, to manage re- 

5 sources efficiently, to allow for smooth upgrades and to 
recover gracefully from hardware and software failures. 
Interchange server services are built out of the base ob- 
ject model and include all the generally useful features 
that the interchange server's components require. 

to Interchange server 20 includes a registry service 
232 to coordinate the interchange server's startup 
processing and allow objects to find other objects by 
name. This includes dynamic registration of new objects 
as they become available. Dynamic registration allows 

J 5 a new application collaboration module to register itself. 
Dynamic registration also enables other clients to locate 
a new collaboration when it comes online. Registry serv- 
ice 232 stores meta-data associated with any compo- 
nent in repository 238 which can be accessed by oth r 

20 tools in the interchange server. 

Dynamic loading service 240 loads the run-time 
pieces of the components and executes them without 
having to re-compile or re-link the interchange server 
20. 

25 Event service 234 provides a publish and subscribe 
notification mechanism. Event service 234 de-cbuples 
information providers from information consumers. The 
notion here is that application collaboration objects may 
wish to subscribe to certain business objects/events that 
30 are published by certain connectors without knowing the 
intimate details about which connectors are publishing 
which objects. The event delivery and subscription serv- 
ice includes subscription receipt (for an event), storage 
of the subscription, receipt of an event, event notification 
35 and object transfer (result) associated with the event for 
each object (application collaboration module, connec- 
tor, or interchange server) that subscribed to the event. 
The event service includes a subscription service 235, 
including a subscription list, and a publication service 
40 236. 

Referring to Figures 3 and 4, in the process of pub- 
lishing and subscribing to an event, a subscription is re- 
ceived from an object (connectors, collaborations or in- 
terchange servers) (400). The subscription service 235 
4 & stores the subscription in a subscription list (402). Upon 
receipt of an event notification (404), the publication 
service checks the subscription list to determine if there 
are any objects which have registered an interest in the 
received event (406). If an object has subscribed to the 
50 event, then the publication service delivers an object as- 
sociated with the event notification to each object in the 
subscription list requesting notification of the particular 
event (408). 

Referring again to Figure 3. messaging service 242 
55 provides asynchronous execution semantics for geo- 
graphically distributed components. Messaging service 
242 includes a reliable queuing and messaging facility 
to allow interchange server 20 to support an asynchro- 
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nous transaction model. Furthermore, the reliable deliv- 
ery mechanism allows message requests to be persist- 
ently queued (in sequence) to the participating compo- 
nent if the participating component is unavailable. When 
the component starts up again, it processes any out- 
standing messages by getting them from the underlying 
persistent queues. In one embodiment, the publish and 
subscribe services are built on top of the messaging 
service to provide an event service which transcends all 
process, system and geographical boundaries of the 
participating components. 

Rules engine service 244 has two aspects, a defi- 
nition aspect and an execution aspect. The definition as- 
pect ties in with the definition of a rule and the execution 
aspect consists of evaluating such rules during execu- 
tion. Application collaboration modules use this service 
lor defining and evaluating the business rules that are 
enforced within the application collaboration module. 
Connectors also use this service when evaluating busi- 
ness conditions or defining new business logic within the 
connector. Lastly, event service 234 may use rules en- 
gine service 244 to evaluate semantic content of a mes- 
sage for message routing and also for publication. 

Data transformation service 246 is provided to per- 
form both syntactic and semantic transformation of data. 
Examples of such transformations range from simple in- 
teger to character conversions to transforming the se- 
mantic content and meaning of a term during a collab- 
oration. For example, a requirement to provide such a 
semantic transformation arises if ■employee" in a first 
application has associated with it two fields (employee 
identification number (B bits) and name), while "employ- 
ee" in a second application has associated with it three 
fields (employee identification number (10 bits), name 
and social security number). When transferring employ- 
ee data from the first application to the second, two 
transformations might be used to synchronize the two 
systems. One transformation would be required to map 
employee number (8 digit to 10 digit) and a second 
transformation would be required to extract an employ- 
ee's social security number from the first application's 
database and add that information into the second ap- 
plication's system. Typically the targets for the transfor- 
mations are defined by the application collaboration 
module and the transformations performed in the con- 
nector. Connectors may also define transformations 
within their execution context, if necessary. 

Transaction service 248 provide consistency 
across applications linked through the interchange serv- 
er. Interchange server 20 provides a transaction model 
for supporting discrete asynchronous transactions with 
compensating transactions. A compensating transac- 
tion is a transaction that can semantically undo the ef- 
fects of a previous transaction. Transaction service 248 
includes one or more qu ues 249 (not shown), and mes- 
sage processor 250 (not shown) for implementing asyn- 
chronous transactions. Transaction service 248 pro- 
vides consistency across applications in two ways. 



Store and forward queues manage transactions des- 
tined for applications that are not on line. Secondarily, 
transaction record queues are used to record transac- 
tion actions. The transaction record queues are used to 
5 recover from transactions that are interrupted, so as to 
re-establish the state of the system prior to the execution 
of the first action associated with an interrupted trans- 
action. 

In one embodiment, sagas are used to maintain 
*o consistency and recover from failures or other shut- 
downs received in the middle of executing a transaction. 
4 A "saga* is a doubly linked list of connected discrete 
transactions that consists of a set of steps (or sub-trans- 
actions) and compensating sub-transactions. To guar- 
's antee consistency, the present invention assures that 
either all the sub-transactions in a saga are completed 
or any partial execution is undone with compensating 
sub-transactions. Each sub-transaction in a saga does 
not assume the same consistent state. Therefore, once 
20 a sub-transaction is complete, it can be committed with- 
out waiting for other sub-transactions of the same saga 
and thus release its results to the rest of the concurrent 
transactions. In case of an interruption, an application 
collaboration module can attempt both forward or back- 
us ward recovery of an interrupted transaction. Compen- 
sating transactions will be discussed in more detail in 
association with the error and exception service 260. 

Referring now to Figures 3 and 5, in a method of 
maintaining consistency in the interchange server, 
30 transaction service receives a notification that a, trans- 
action is to be initiated by an object, such as an appli- 
cation collaboration module in response to a event no- 
tification (500). When an application collaboration mod- 
ule receives notice of an event, it initiates a saga initia- 
ls tion transaction request (or for that matter when any ob- 
ject in the interchange server initiates a transaction). 
Transaction service 248 responds to the saga initiation 
request by allocating a recording queue to store the ac- 
tions associated with the transaction initiated by the ap- 
*o plication collaboration module (502). The transaction 
service 248 returns a saga identifier associated with the 
recording queue to the object initiating the transaction 
request (504). 

Thereafter, the application collaboration module ex- 
45 ecutes steps/actions according to its business inter-op- 
erabifity function. As each action (also called transaction 
step) is initiated, the application collaboration module 
generates a request for adding the step in the appropri- 
ate saga queue. The transaction service enters a loop 
so and waits for the next request from the requesting object 
(506). The types of requests that can be received are 
add (508). delete (510), modify (512). get (514). undo 
(516) and end transaction (526). 

If the next request is an "add' request, then the ac- 
55 tion associated with the "add* request is stored in the 
recording queue along with compensating transaction 
information (518). If the next request is a "delete" re- 
quest, then the requested entry (action) from the queue 
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is deleted (520). If the next request is a "modify" request, 
then an entry in the queue is modified according to the 
request (522). If the next request is a "get" request then 
the designated portions of the queue (saga) are re- 
turned to the requesting object (523). Finally, if the next s 
request is a undo request, a compensating transaction 
sequence associated with the actions stored in the 
queue is retrieved from saga and initiated (524). At the 
completion of a transaction (upon receipt of an end 
transaction request), the saga is removed (526-530). io 

In one embodiment, in the event a transaction is in- 
terrupted, a compensating engine within the transaction 
service executes compensating actions to undo the sa- 
ga stored in the recording queue associated with the 
partially completed transaction. Aborting a transaction is 
is accomplished by executing a corresponding compen- 
sating transaction for each action (sub-transaction) in 
the saga queue. The compensating transactions pro- 
vide a logical or semantic "rollback" (since the transac- 
tion has already committed). For example, the compen- 20 
sating transaction for "add employee" may be "remove 
employee". However, the compensating transaction 
may not be so simple. For example, a human resources 
user may be mystified if a new employee simply disap- 
peared from the system because some project tracking 25 
system, possibly located in another department in an- 
other location, rejected it. Accordingly, other more com- 
plicated compensating transactions are defined. 

In one embodiment, a 2PC (Two Phase Commit) co- 
ordinator is used to coordinate the queuing of messages 30 
to multiple queues participating in the application collab- 
oration. When a single collaboration provides the under- 
lying messaging service to send messages to 5 appli- 
cations, the two phase commit coordinator guarantees 
that either all the 5 messages will be transmitted or none 35 
of the messages is transmitted. 

Providing asynchronous transactional semantics in 
a connector involves identifying transactional objects, 
its transactional methods and providing the necessary 
functions (compensating transactions) to compensate *o 
for these methods. The content of compensating trans- 
action functions is collaboration specific implying that 
the processing logic could be different for each method. 
In most cases, hand-coding the compensating transac- 
tions will be required. In one embodiment, the inter- 
change server is able to dynamically enable and disable 
the execution of the compensating transaction functions 
in any connector. 

Error and exception service 260 provides notifica- 
tions and hooks to handle errors. Error and exception so 
service 260 provides a notification of any error identify- 
ing the component where the error occurred, location of 
such component, the nature of the error in the form of 
an error number and string. In the event a transaction is 
interrupted, the error service issues a undo request to ss 
the transaction service to initiate the "undo" actions 
stored in saga. Alternatively, the error and exception 
service may notify the appropriate application collabo- 



ration module of the error. The application collaboration 
module may thereafter attempt both forward or back- 
ward recovery of an interrupted transaction. In a back- 
ward recovery, the- application collaboration module is- 
sues an undo request to the transaction service to undo 
any transaction steps completed in the interrupted 
transaction. Alternatively, a forward recovery seeks to 
continue the interrupted transaction by evaluating the 
particular error and deciding if it is critical. If not, a work- 
around is employed. 

The exception service allows users of the service 
to register resources which can be de-registered easily 
in case of exceptions in processing. 

Other services may be provided by interchange 
server 20 including: a timer service, to let connectors 
and application collaboration modules have pre-defined 
schedules for executing certain operations; thread and 
synchronization service, to allow many operations in the 
interchange server to be executed in parallel; licensing 
service; persistency service, to allow tor persistently 
storing objects or object state outside that of an appli- 
cation; interface versioning service, to detect changed 
versions of the components interfaces; component ver- 
sioning service, for detection of changed components, 
such as connectors which are upgraded or downgrad d; 
other RAS feature services including upgrading, report- 
ing and diagnosing bugs, performance monitoring and 
tuning. 

In one embodiment, interchange server 20 (and ap- 
plication collaboration modules) are constructed in Java 
because of its cross-platform capability of execution. In 
one embodiment, the backbone of interchange server 
is a CORBA Object Request Broker (ORB) written in 
Java, produced by Visigenic, Co., Foster City, Califor- 
nia, USA. The ORB operates in a Java run-time envi- 
ronment. The necessary CORBA services are utilized 
from Java (using the IDL to Java generation, consisting 
of Java stubs for the client and Java skeletons for the 
server). Communication transport in this scheme 
amongst interchange servers is HOP (Internet inter orb 
protocol) or messaging. The communication scheme 
between the two halves of the connectors or between 
interchange servers and connectors can be HOP or 
messaging. 

A process flow for interchange server 20 is shown 
in Figure 6. Referring now to Figures 3 and 6, at start- 
up, the interchange server is initialized (600). The ini- 
tialization includes retrieving configuration information 
from the repository associated with registry service.232 
including application collaboration module and connec- 
tor information as well as interchange services informa- 
tion. Thereafter a check is made to determine if an error 
arose in the configuration (602). An error may arise if 
there are configuration errors in a connector or applica- 
tion collaboration module specification or if some serv- 
ice has invalid and unsupported options specified. If a 
critical error occurs (604), such as m ssaging service 
not available, then the initialization halts (606). 



7 



13 



EP 0 853 277 A2 



14 



If no error is detected or if the rror is not critical (for 
example, connector not having specified some proper- 
ties but has defaults), th n a check is made to determine 
if all of the service in interchange server are available 
(608). If any critical services are unavailable (610), then 
the initialization terminates. Else, the interchange server 
instantiates each installed and configured connector 
(612) and application collaboration module (614). 
Thereafter, the interchange server enters a steady state 
loop waiting for service requests. Upon receipt of a serv- 
ice request (616), the interchange server checks to de- 
termine if the request is a shutdown request (618). 

If so, the interchange server executes a shutdown 
procedure (620). If not, the interchange server services 
the request (622), and then idles until the next request 
for service is received. 

The servicing of requests is shown in more detail in 
Figure 7. A request type is determined (700). If the re- 
quest is an interchange service request branch A is in- 
voked. If the request is a transaction request branch B 
is invoked. If the request is a management request 
branch C is invoked. Finally, if the request is a configu- 
ration request branch D is invoked. 

In branch A, interchange service requests are proc- 
essed by the appropriate interchange server service 
module in the interchange server (702) and a result is 
returned (704). For example, the request may be in the 
form of an event notification. The event notification is 
received by the event service and thereafter an object 
is distributed to each object (application collaboration 
module, connector or other interchange server) which 
subscribed to the particular event notification received. 

In branch B, the type of the transaction request is 
determined (706). In one embodiment, the transaction 
types include a create transaction saga (for creating a 
transaction saga queue), and saga operations (add. de- 
lete, return, or undo saga). If the request is a create 
transaction saga (707), the transaction service allocates 
a recording queue for the new transaction and returns 
an identifier for the saga (708). Alternatively, if the trans- 
action received is a saga operation (709), the transac- 
tion service operates on the existing saga, and returns 
either an acknowledgment of the operation or executes 
a compensating transaction in response to an undo re- 
quest (710). 

In branch C, management requests are typed (7 1 2). 
and thereafter operated on by the appropriate service 
(for example by the error and exception service )(7 14). 
In one embodiment, the management requests include 
the logging of errors; starling, stopping, and passing of 
objects in the interchange server domain; performance 
data collection; and. event logging and diagnosis. Man- 
agement requests can be generated by objects within 
the interchange server or from a system management 
tool through the system management interface 209 (Fig. 
3). 

In'branch D. configuration requests are operated on 
by the configuration service. Configuration requests can 



be generated by connectors, collaborations, inter- 
change server objects or by the configuration tool. Con- 
figuration requests include the installation or removal of 
application collaboration modules and connectors; acti- 

5 vation or deactivation of connectors or application col- 
laboration modules: and version tracking and upgrade 
functions. The configuration service executes the con- 
figuration request (716) and returns an acknowledg- 
ment (or result) to the requesting object (or user) (718). 

io Thereafter, the process continues at step 622 (Figure 
6), waiting for the next request for service. 

Referring now to Figures 3 and 8, the shutdown 
process (step 620 in Figure 6) includes issuing shut- 
down requests to each application collaboration module 

is (800). A check is made to determine if acknowledgment 
signals to the shutdown requests issued in step 800 
have been received (802). Each collaboration responds 
to a shutdown request by executing its own shutdown 
procedure. As part of this execution an acknowledgment 

20 signal is returned to interchange server 20.* If an ac- 
knowledgment signal has not been received, then a 
check is made to determine if a time out has expired 
(804). In one embodiment, the time out is set to allow 
for the orderly shutdown of each component. A long time 

2S out allows for the completion ol tasks. If a time out is 
selected that is too short, some transactions executing 
in a component may be terminated prior to completion 
of a entire transaction, necessitating the execution of 
compensating transactions. Alternatively, the time out 

30 can be set to a short time period to lorce an immediate 
shutdown of the system. 

If the time out has yet to expire, the interchange 
server waits until the receipt of the last acknowledgment 
or the expiration of the shortest timeout. 

3S If the time out expires, interchange server (through 
the application collaboration module) initiates an undo 
transaction for servicing by the transaction service 248 
(806). Thereafter, the transaction service executes the 
compensating transactions required to maintain con- 

40 sistency in the interchange server (807). 

Upon receipt of the last acknowledgment or the 
completion of the last compensating transaction, inter- 
change server 20 generates a connector shutdown for 
each instantiated connector (808). Each connector re- 

45 sponds to a shutdown request by executing its own shut- 
down procedure. As part of this execution, an acknowl- 
edgment signal is returned to interchange server 20. A 
check is made to determine if all the acknowledgment 
signals have been received (810). If an acknowledg- 

so menl signal has not been received, then a check is made 
to determine if a time out has expired (812). In one em- 
bodiment, the time out is set to allow for the orderly shut- 
down of each connector. If the time out has yet to expire, 
the interchange server waits until the receipt of the last 

55 acknowledgment or the expiration of the shortest time- 
out. 

If the time out expires or upon receipt of the last ac- 
knowledgment signal, interchange server initiates an or- 



8 



15 



EP 0 853 277 A2 



16 



derly shutdown of its own services and components 
(814). 

Application collaboration modules 

Typically, application integration is achieved 
through the "cooperation" of one application's objects 
with another application's objects. In the interchange 
server, application objects are represented as virtual ob- 
jects by their respective connectors. These business vir- 
tual objects cooperate with other business virtual ob- 
jects (from another application) and utilize facilities of 
"service" objects to perform the application integration 
function. This cooperation or interaction amongst the 
various application objects defines and captures the ap- 
plication integration semantics and is encapsulated and 
stored in the form of an application collaboration module 
in the interchange server. All multi-object application 
collaboration modules are stored and treated as a first 
class entity in the interchange server and are referred 
to as an application collaboration object. The application 
collaboration object encapsulates the business logic 
and business process flow required to perform applica- 
tion integration. 

Referring now to Figures 1 , 3 and 9. an application 
collaboration module 40 includes a object representa- 
tion module 900, a business scenario module 902, and 
messaging communication module 904. 

Application collaboration module 40 resides as an 
application collaboration object in interchange server 
20. An application collaboration object identifies all par- 
ticipating interchange (connector and "service") objects 
and the "business scenarios" amongst these objects. 

Object representation module 900 includes meth- 
ods associated with the application collaboration object 
including consume methods, receive methods and ob- 
ject generation methods. This module also defines the 
abstracted re-usable classes and methods that are 
needed to participate in a given collaboration. 

Messaging communication module 904 processes 
event notifications and subscriptions. Event subscrip- 
tions are generated for transmission to event subscrip- 
tion service 235. Event notifications are received from 
event publication service 236. 

Business scenario module 902 includes a business 
scenario defining a temporal ordering of message ex- 
changes between cooperating applications. It also de- 
fines the reaction of these application objects to such 
messages. Defining the business scenario includes 
identifying the participating attributes and methods for 
the collaborating application objects. Object reaction 
behavior is described by a set of declarative constraints 
and causal rules which may be enabled unconditionally 
or based on the state of the object. 

Ail communication between applications is man- 
aged and enforced by application collaboration objects. 
Application collaboration objects allow interchange us- 
ers to define interactions between connector objects. 



One example of an application collaboration module is 
automatically generating an invoice and adding the 
amount to the accounts receivable entry in a financial 
system when a customer support application logs a new 

5 support call. 

An application collaboration object is defined by a 
set of business scenarios stored in business scenario 
module 902. An application collaboration module has a 
single, business process oriented function. Several ap- 
plicable collaborations may exist between any two ap- 
plications, and collaborations may involve more than 
two applications. The single business process function 
may involve multiple transactions, also called scenarios. 
For example, an application collaboration module which 

'5 replicates employees across two or more applications 
would require handling hiring, firing, and status chang- 
es, all of which constitute different scenarios for the 
same application collaboration module. 

Application collaboration modules are controlled 

20 through property sheets. Property sheets are the cus- 
tomers interface to control the configuration of an appli- 
cation collaboration module or any of its participating ap- 
plication objects. Examples of application collaboration 
module properties are diagnostic level, user name/ 

25 password, and integration scenario specific propeni s. 
Properties of the participating application objects in- 
clude setting the maximum, minimum and default values 
lor any of the attributes of these application objects, and 
the values of integration specific properties. 

30 Since application collaboration objects are first 
class entities, they display typical object properties such 
as inheritance, polymorphism, etc. Application collabo- 
ration objects expose a well-defined interface in order 
to allow it to participate as an application object in an- 

35 other collaboration. 

Referring now to Figure 10, a message flow be- 
tween objects for a bill-by-call business scenario is 
shown in which the arrows from one object to another 
define the object interactions as ordered message flows 

40 between these objects. A business scenario includes 
identifying the message flows, the participating applica- 
tion objects, their attributes and methods, and the busi- 
ness rules associated therewith. Execution of any busi- 
ness scenario in an application collaboration module 

4S may typically be triggered by an event or message gen- 
erated by an interchange service object, a connector ob- 
ject or another application collaboration object. 

Referring again to Figure 9, each scenario or set of 
object interactions is reduced and encapsulated into a 

so Finite State Machine (FSM) 906. When triggered by an 
event, the FSM represents the process flow. To exert 
further control events, conditions and actions can be 
manipulated directly in the FSM to modify interaction be- 
havior. The FSM associated with each scenario is stored 

55 as an attribute for that application collaboration object 
and is triggered by an event or message sent to that 
application collaboration object. 

FSM implementations may be decomposed such 
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that "actions" in the FSM translate into one of the follow- 
ing mechanisms, based on location, transaction and 
performance requirements for the application collabora- 
tion module and the participating application objects at 
execution time. These mechanisms may include func- s 
tion dispatching (a simple local or remote function call), 
which is synchronous: messaging, which is similar to re- 
mote function dispatching except that it will perform 
asynchronous execution of the function (this is achieved 
by sending a message to a remote object with a request io 
to execute some function using a reliable delivery capa- 
bility of the messaging system); and event generation 
or state change within the same or another FSM. The 
function calls may implement business rules for operat- 
ing on attributes of objects, or data received through *s 
messaging or event services. 

In one embodiment, application collaboration mod-' 
ules are generated tn the Java language and extend the 
base collaboration Java class and interface (also known 
as sub-classing in object systems). 20 

Referring now to Figure 11, in a method for con- 
structing an application collaboration module, an appli- 
cation collaboration module builder defines a configura- 
tion of inter-related application objects required to per- 
form the cross-application integration (1100). Such con- 2S 
figuration should represent a single business process 
ranging from a simple to a more complex integration 
such as integrating a manufacturing schedule plan in a 
supply chain optimization application with an ERP (En- 
terprise Resource Planning) application. Defining this 30 
configuration includes identifying the participating appli- 
cation objects (1102), their attributes and methods re- 
quired to perform the required application integration 
(1104) and a ■relationship" between the application ob- 
jects (1106). 35 

Thereafter the set of business scenarios driving the 
message interactions amongst the application objects 
within the application collaboration module is identified 
(1108). Each scenario may represent a business proc- 
ess, a system management scenario, or a set of "busi- *o 
ness" transactions from the user's view. The set of all 
scenarios that logically perform participating functions 
in a single business process are grouped into one ap- 
plication collaboration module. 

After defining the scenarios, the generic set of <*$ 
classes and their relationships which consolidate and 
abstract the structure and behavior of the application ob- 
jects is identified (1110). 

Finally, the behavior is modeled (1112). The model 
may be decomposed by dividing it into iterative steps to so 
create a finer granular form if needed (1114). This allows 
iterative development such that the solution starts from 
the highest business model and iterates down to fine 
grained service objects as needed. 

Application collaboration objects are re-usable 55 
across application objects d rived from different ven- 
dors for the same application class. This is achieved by 
having the application collaboration object request the 



participating application object for the required business 
behavior (method) and by not incorporating or develop- 
ing such behavior as part of the application collaboration 
object itself. All such vendor specific functionality is en- 
capsulated in connectors, allowing the application col- 
laboration module objects to be re-usable across differ- 
ent vendor's application for the same application class. 

Application collaboration objects are installed in the 
interchange server using the set-up and configuration 
tools. Configuration tools allow setting the property 
sheets associated with the application collaboration 
module such as setting the billing rate in a bill-by-call 
collaboration when that value is not available from any 
of the participating applied ions. 

In addition, application collaboration modules allow 
for configuration of various properties which control 
runtime and processing criterion such as: instantiation 
characteristics (start-up or event); transaction seman- 
tics (synchronous 2PC with participating applications or 
asynchronous messaging with compensating transac- 
tions); execution timing (scheduled and timed); and en- 
ablement (enable/disable) of any participating business 
scenarios. 

A process flow associated with application collabo- 
ration module 40 (Fig. 1) is shown in Figure 12. Refer- 
ring now to Figures 3 and 12, application collaboration 
module receives an initialization request from inter- 
change server 20 as part of the instantiation process 
(1200). The application collaboration module issues 
event subscriptions associated with the business see-, 
nario storedwithin the business scenario module. (1 202) 
and then returns an acknowledgment signal to inter- 
change server 20 in response to the initialization request 
(1204). Thereafter, application collaboration module 
waits for the delivery of a subscribed event to trigger the 
beginning of a collaboration or an administrative request 
from the interchange server (such as a shutdown). 

Upon receipt of an event notification (and associat- 
ed object), or in response to an object received from in- 
terchange server 20 or application connector 30, busi- 
ness scenario module 902 (Fig. 9) executes the meth- 
ods called for in the object. If the object is an event no- 
tification (1207), the business scenario module requests 
a new saga from the transaction service (1208). Upon 
receiving a new saga request acknowledgment from the 
transaction service, business scenario module 902 (Fig. 
9) initiates (1210) and executes (1211) the finite state 
machine associated with the scenario stored within the 
business scenario module. At each sub-transaction 
within the scenario, business scenario module requests 
the transaction service to record the underlying sub- 
transaction in the saga (121 2). Thereafter, the business 
scenario module operates on the data received in the 
event notification (or object delivery) (1214) and gener- 
ates objects (by object representation module 900 of 
Fig. 9) for transmission to one or more application con- 
nectors (1216). The process continues generating sub- 
transaction requests and objects until an end of the sce- 
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nario is reached (FSM execution terminal s) (1218) or 
a forced shutdown request is r ceived (1220). 

If the finite state machine has executed to termina- 
tion, then a final transaction request is generated and 
transmitted to the transaction service to delete the saga s 
stored therein (1222). Thereafter, a check is made to 
determine if a shutdown flag (either a "graceful" or 
Forced" shutdown flag) has been set (in steps 1 230 and 
1233) (1223). If so, then a shutdown of the application 
collaboration module is initiated (1224). If not. then the io 
process continues at step 1206. 

If a forced shutdown flag is set at step 1 220, then a 
saga undo request is issued to the transaction service 
(1226). Thereafter, the application collaboration module 
initiates its shutdown 1 224. Alternatively, the application - 'is 
collaboration module may attempt to complete all trans- 
actions after a forced shutdown is received and there- 
after invoke its own shutdown procedure at the comple- 
tion of any ongoing transaction process. 

If the object received at step 1207 is not an event 20 
notification, then a check is made to determine if the ob- 
ject received is a forced shutdown request (122S). If so, 
a check is made to determine if a finite state machine is 
executing in the application collaboration module 
(1229). If not, then application collaboration module will 25 
initiate its shutdown procedure (1224). If a finite state 
machine is executing, then a "forced" shutdown flag is 
set (1230) and the process continues at step 1206. 

If the object received is not a forced shutdown re- 
quest (step 1228), then a check is made to determine if 30 
the object received is a "graceful" shutdown request 

(1231) . If so, then a "graceful" shutdown flag is set 
(1233) and the process continues at step 1206. If not, 
then the object is in response to a request generated by 

the application collaboration module due to the execu- 35 
tion of an existing finite state machine. Accordingly, the 
execution of finite state machine may be resumed 

(1232) . 

During operation, error and exception service 260 
(Fig. 3);. monitors the state of services and interchange *o 
server components. If an error occurs, the error and ex- 
ception service generates an error signal for transmis- 
sion to the application collaboration module. If the error 
is fatal (e.g. the messaging service has failed), then the 
application collaboration module initiates a backward *s 
recovery and then performs a shutdown. If the error is 
not fatal, then a determination is made whether the col- 
laboration needs to be terminated. If the collaboration is 
itself the source of the error, then the collaboration is 
required to be shutdown and accordingly, a backward 50 
recovery is initiated followed by a shutdown of the ap- 
plication collaboration module. Alternatively, a forward 
recovery may be attempted if the error does not impli- 
cate the application collaboration module itself. 

55 

Collaboration Definition Tool 

Collaboration builders are not required to write pro- 



cedural programs to build collaborations. The collabo- 
ration definition tool reads the repository to get th busi- 
ness objects supported by installed connectors and the 
generic class hierarchies available to collaboration de- 
velopers. This information is presented to collaboration 
developers in a visual, hierarchical form. 

Collaboration developers may use these applica- 
tion classes and model them as objects using the sup- 
ported object modeling methodology's visual notations. 
The application integration scenarios may be modeled 
by drawing lines and arrows to signify message ex- 
changes amongst the application objects available and 
by picking from a list of supported methods (correspond- 
ing to application objects), the method to invoke as a 
reaction to a received message along with appropriate 
arguments. Business rules and constraints are defined 
through the use of an integrated rules definition table 
and incorporated into the business scenario diagrams 
at well-defined anchor points. Any data transformations, 
if needed, are similarly defined using a data-transforma- 
tion tool with hooks to anchor in such transformations 
into the application integration scenario. Collaboration 
developers are thus able to build the entire collaboration 
using visual tools. An example is shown in Figure 10. 
This is just a sample visualization, the actual visual will 
depend on the object modeling methodology supported 
by the modeling tool. 

After the collaboration has been visually model d 
and all pans of it is defined, the collaboration definition 
tool reduces the business scenarios into a finite state 
machine and generate configuration information and 
Java class files. All collaboration configuration, includ- 
ing details of participating objects/classes, 'their at- 
tributes and participating methods, relationships be- 
tween the objects, the finite state machine, configured 
properties such as locational, execution and transac- 
tions semantics, etc. are stored in the repository during 
collaboration installation. The supporting Java class 
files depicting the collaboration and generated by the 
collaboration definition tool are stored in a well-defined 
location and a path to this is stored in the repository. 

The application collaboration module, once in- 
stalled can be configured and managed by other inter- 
change tools as needed. For collaborations that require 
new business objects, programmatic tools are available 
to let such objects be created and built either by using 
the connector development toolkit (if new objects are to 
come from a connector) or by writing Java code, if the 
object is local to a collaborator 

Connectors 

Connectors interface between the interchange 
server and business applications. Each connector is ap- 
plication area and vendor specific. The connector utiliz- 
es the application's API, and transforms data and oper- 
ations in the application to and from the int rchange 
server's object and vent model. For example, an hu- 
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man resources (HR) application may have the concept 
of an employee, and mechanisms for adding employees 
and changing their salary. The corresponding applica- 
tion connector provides a representation of the employ- 
e in the interchange server's object model. It is the re- 
sponsibility of the connector to detect and keep track of 
changes in the application, and if necessary issue 
events. 

Connectors manipulate the application API's to ex- 
tract information from and deposit information to the ap- 
plication. Information in this context means both data 
and function. 

Connectors represent the data and function from an 
application in interchange server as an application ob- 
ject. The application object model follows the base ob- 
ject model defined by the interchange server. 

Connectors also bridge any semantic and syntactic 
gaps between application's data and behavior and its 
representation in the interchange server. This involves 
performing appropriate data transformations and imple- 
menting behavior semantics needed to present applica- 
tion data and behavior into the defined object model. 

Connectors also incorporate vendor/application 
specific business rules and logic (constraints) needed 
to provide the correct behavtoral semantics expected by 
the application collaboration module. For example, an 
application collaboration module may expect customers 
only from the 'North American" region while the appli- 
cation may not distinguish between regions. In such 
cases, the connector includes business logic to only pick 
up those customers which fail in the "North American" 
region. 

In addition, connectors provide application and/or 
vendor specific functionality needed by an application 
collaboration module, which is not provided by the ap- 
plication, by incorporating it within the connector. An ex- 
ample here is a financial accounting system which does 
not provide a billing function. For a bill-by-call applica- 
tion collaboration module, such a billing function is in- 
corporated in the connector for the financial application. 

Finally, connectors provide event notifications to 
application collaboration modules and interchange 
servers when changes in applications occur. 

Other functions provided by the connectors include 
error handling and communication "middleware" (to 
communicate with the interchange server for in-proc- 
ss. out-of-process and over local and wide area net- 
work topologies). Connectors also support manage- 
ment interfaces to allow management tools to manage 
the connector as any other component, install, setup 
and configure connectors, and provide security (for se- 
cure transactions between connectors and the inter- 
change server). 

Referring now to Figure 1 3, a connector 30 includes 
an API manipulator 1300, a data transformer 1302. a 
business rules and constraint module 1304, a business 
encapsulation module 1 306, a message transformer 
1308, a communication module 1310. an object repre- 
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sentation module 1312. a configuration tool set and 
management interface 1314 and error handler 1316. 

Typically, an application connector does not interact 
directly with the application's data which may be resid- 

5 ing in a Data Base Management System. Instead, the 
interchange operates against vendor supplied API's us- 
ing an application specific API manipulator 1300. This 
allows all connector operations to run against the appli- 
cation's own processing logic, thereby reducing the de- 

10 pendency on the application vendor's internal logic and 
schema changes. For example, in a customer support 
application, adding a new customer in a customer table 
requires that the customer agreement information (bill- 
ing rate, support level. 24x7 support information, etc.) 

15 be updated in an agreement table. API manipulation is 
the most vendor (and application) specific part in any 
connector and is layered at the bottom of the connec- 
tor's logical stack. 

Connectors provide bi-directional syntactic and se- 

20 mantic transformations when going from applications', 
data and function into the interchange server object 
model and vice-versa. These functions are provided by 
the data transformer 1302. the business rules and con- 
straints module 1304 and business encapsulation mod- 

2S ule 1306. 

Data Transformer 1 302 transforms the application 
data and function to a data format suitable to the con- 
nector. Data transformer includes an interactive tool 
1320 to visually define the data formats for transforma-, 

30 .. tion, which will be bundled with the connector develop- 
ment toot, and a runtime component 1322 which per- 
forms the actual transformations and is embedded in the 
connector executable code. Interactive tool 1320 de- 
scribes the input and output formats and appropriate 

35 conversions. These conversions range from implicit 
syntactic conversions to semantic -content based con- 
versions. The tool provides mathematical (+, -, *,/,.. ), 
string (truncate, append, etc. ), logical (>,<. >=, etc. ) 
and boolean (AND, OR, NOT, etc. ) operators which 

•to work on the contents of input and output fields. It also 
provides hooks to incorporate foreign language func- 
tions, if needed. Examples of foreign language functions 
are functions that may read an external table from a dif- 
ferent data source such as a flat file for validating infor- 
ms mation. Typically, data transformations are performed 
as soon as the data is read from the application or just 
before the data is written into the application, or, de- 
pending on the application collaboration logic, may b 
performed in different points in time for a given connec- 

so tor. 

Business rules and constraints module 1304 in- 
cludes a tool to define a set of rules 1 330 which contain 
the information necessary to enforce vendor specific 
business rules and a rules engine 1332. The rules en- 
55 gine 1332 evaluate the rules. For example, a business 
application may provide business records for customers 
from across the world. A collaboration may only require 
the records associated with a particular geographical re- 
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gion. The business encapsulation module provides a 
sere n to filter such records and only provides those ap- 
propriate records as objects to the application collabo- 
ration module by having a business rule (stored in the 
set of rules 1330) which fitters such records. 

Business encapsulation module 1306 adds busi- 
ness functionality which is not provided by the applica- 
tion but is required by the application collaboration mod- 
ule. For example, if a customer support application does 
not keep track of the accumulated time for all support 
calls logged against a case, then the business encap- 
sulation module 1306 is used to accumulate and store 
persistently the time logged against a case by totaling 
the time for each support call in the database as required 
to provide the business functionality desired 

Event notifications initiate processing in an applica- 
tion collaboration module. Events are also used to com- 
municate changes between various components. 
Events are generated from connectors to allow applica- 
tions to communicate modifications in the application's 
data to the interchange server. Connectors keep track 
of changes occurring within the application and commu- 
nicate them through events to the interchange server. 

Connectors rely on persistent event notification 
from applications by having connectors queue them into 
a reliable messaging system to prevent loss of such 
events in case of failure within the components. In case 
of connector failure, the connector determines and com- 
municates to the interchange server all changes that oc- 
curred after the connector failed. The message trans- 
former 1308 and communication module 1310 provide 
the message oriented middle-ware (MOM) to transport 
messages within connectors as well as between con- 
nectors and interchange servers. A similar mechanism 
is used in interchange servers. Messaging middle-ware 
provides the asynchronous semantics needed by the 
execution environment to support inter-operability be- 
tween geographically distributed applications by provid- 
ing sequential queuing with reliable delivery. This pro- 
vides assurance that applications do not wait for ac- 
knowledgments over slow wide area networks and they 
can continue doing work. The underlying assumption is 
that the message queued to a remote system will defi- 
nitely be delivered. MOM also provides the semantics 
for handling instances when the application is unavail- 
able by queuing their messages to a persistent store. 
When the application starts up again it retrieves its mes- 
sages from the store, in the correct order, and processes 
them. This MOM implementation also provide time-outs 
on messages in order to expire messages and generate 
errors requiring transaction abort and recovery in the 
collaboration. 

Object representation module 1312 builds object 
wrappers around the application's data and behavior 
and present it using the interchange server's base ob- 
ject model. The wrappers provide a framework to accu- 
rately represent the application's data and function 
schema as required by the application collaboration 



module, irrespective of whether such data and function 
reside in the application or the connector itself. Wrap- 
pers also interpret the generic framework and represent 
the framework contents in the interchange server's base 
s object model. This is a bi-directional mechanism which 
also converts from the interchange server's object mod- 
el into the framework for execution in the connector. Fi- 
nally, the wrappers provide semantic content in a spe- 
cific wrapper or framework, which describes the mean- 

io jng of a given application object, such as what are its 
attributes and its functions and what do they do. 

In one embodiment, connectors are built using any 
language and are exposed to the interchange server us- 
ing Java wrappers, CORBA IDL or Microsoft's OLE/Ac- 

75 tivex technology. Interchange server provides hooks for 
invoking (tying in) components in any of the above stat- 
ed forms. A base connector class/interlace is defined 
which is extended to provide base classes for the 3 
types (Java, IDL and OLE/Activex). 

20 Application objects are represented by their class 
definitions at the time of application collaboration mod- 
ule creation. It is only at run-time that application objects 
are instantiated by the connector as virtual objects. Ap- 
plication collaboration objects are independent of the 

25 participating application's platform of execution. Mini- 
mally, they execute on the same platform on which the 
interchange server executes. 

Error handler 1 316 synchronizes with managem nt 
interfaces, logging facilities and error handling services. 

30 in other components. Configuration tools 1314 support 
various management interfaces. These interfaces ad- 
here to platform specific management interlace stand- 
ards so that existing management tools are able to man- 
age the connector process. Configuration tools also al- 

35 low for the installation of application connectors. 

An application connector is a component which op- 
erates like an "object factory". This means that it sup- 
ports an interface that can do things like "create object", 
"get object", "destroy object". These objects include 

*o connector, application and virtual objects. They repre- 
sent objects, data, and services provided by the appli- 
cation, collaboration or server. In many cases, these ob- 
jects are "proxy" objects. They represent remote objects 
but don't actually contain any object state. 

-*5 When the interchange server needs to access a 
connector object, it gets a "handle" to that object. From 
the perspective of an interchange server, any object pre- 
sented by a connector is similar in that the interchange 
server does not care where exactly that object resides 

so (data and function). Neither does it keep track of state 
information for connector objects. State information for 
the object, if necessary, is maintained by the connector. 
If the collaboration needs some state of a connector ob- 
ject, then it creates a local object which is a snap-shot 

55 copy of the connector object and uses that for local 
processing. Collaborations cannot rely on connectors to 
maintain any object state information unless explicitly 
required for transactional consistency. In one embodi- 
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ment, connector objects are cached to speed perform- 
ance of the collaboration process. 

Each application connector supports a set of pre- 
defin d object "types" that it knows how to deal with. An 
HR application, for example, supports an employee 
type. A customer service application supports a custom- 
er type. All application connectors are required to sup- 
port a minimal set of facility object types for the purpose 
of providing required services, for example an event 
service type, an event type, a transaction service type, 
a transaction type, a receive method, a consume meth- 
od, etc. In one embodiment, the object representation 
module uses an event-based publish and subscribe 
mechanism in lieu of looking at events just from a serv- 
ice perspective, thus events are just another form of 
business object which are published and subscribed to. 

When an object is received either due to an event 
subscription or in response to the invoking of a consume 
method, a connector communicates with the applica- 
tion, retrieves the data necessary to construct the re- 
quested object (for example, generate queries to a da- 
tabase), applies the necessary data transformations, 
rules and business logic, constructs the object, and re- 
turns a handle to the object to the requester/subscriber 
by invoking the requester's receiveDelivery or consume 
methods. 

The connector communicates with the application 
by either calling the application API directly, or by com- 
municating with a gateway process which in turn, calls 
the application API. Such communication can be 
achieved more efficiently using an event based publish- 
subscribe mechanism. 

Events in the interchange server may be external 
or internal. Internal events are those generated by the 
services within the interchange server such as applica- 
tion collaboration modules, timers, synchronization 
primitives, other services. External events are those 
generated by external components such as connectors 
or other interchange servers. 

Referring now to Figures 1 3 and 14, a process flow 
for connector 30 is shown. At initialization, connector 30 
publishes a list of events that it is responsible for in each 
collaboration (1400) The connector then subscribes to 
events according to its associated business scenario by 
providing an event subscription via message transform- 
er 1 308 to the interchange server (1 401 ). Thereafter, the 
connector waits for the receipt information form either 
the application or the interchange server. Information 
from the application may take the form of event trigger- 
ing information or information returned from the appli- 
cation responsive to a request for information from an 
application collaboration module. Information the inter- 
change server may take the form of a business object 
request from the application collaboration module or the 
return of a requested business object from the collabo- 
ration based on a subscription by the connector. If ap- 
plication information is received by the connector 
(1402). data transformer 1302 converts the information 



into the appropriate format for business rules and con- 
straints module 1304 (1406). Business rules and con- 
straints module 1304 executes a run time evaluation of 
th associated rules to incorporate the specific vendor/ 

5 application semantics exp cted by the application col- 
laboration module (1408). Business encapsulation 
module adds business functionality which is not provid- 
ed by the application but is required by the application 
collaboration module (1409). 

io Thereafter an event notification is generated by 
message transformer 1308 (1410) and an appropriate 
object is created according to the interchange object 
base model by the object representation module 1312 
(1412). The object and event are transferred as a busi- 
es ness object to the application collaboration module by 
the communication module 1310 via the interchange 
server (1414). 

If interchange server information or requests are re- 
ceived, such requests (or responses to requests) is 

20 processed by message transformer 1308 (1*416) and 
the object is transformed into the appropriate format for 
the connector by the object representation module 1312 
(1418). The encapsulation module adds any functional- 
ity that is required at the connector level (1420). There- 

25 after, the business rules and constraints module 1304 
executes a run time evaluation of the associated rul s 
to incorporate the specific vendor/application semantics 
expected by the application (1422). Data transform r 
1302 converts the information into the appropriate for- 

30 mat for API manipulator 1300 (1424), which in turn 
transfers the information to the application (1426). The 
information returned to the application may be in the 
form of data to be manipulated by the application or a 
request for data to be used in the collaboration. 

35 This process continues until a shutdown request is 
received. A shutdown request may include a compen- 
sating transaction, or may only require the shutdown of 
the connector. Upon receipt, connector 30 performs any 
compensating transactions received from the exception 

40 service or an application collaboration module then ini- 
tiates its own shutdown procedure. 

Administrative tools and Interlaces 

45 Referring now to Figure 15, administrative tools 50 
(Figure 3) includes an installation tool 1502. set up tool 
1504, a configuration tool 1506, and management inter- 
faces 1 508. 

Installation tool 1 502 is used for installing, collecting 
50 required parameters, and removing components in the 
interchange server. The installation tool is meta-data 
driven such that the Information that guides the tool is 
stored in the components themselves, rather than being 
known intrinsically by the tool. 
55 The setup tool 1504 installs a component into any 
interchange server within its administrative domain. 

Configuration tool 1506 is also a meta-data driven 
tool for viewing and changing the configuration of in- 
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stalled interchange servers, application collaboration 
modules and connectors. In addition to configuration, it 
also allows customers to enable or disable executing 
components. Configuration meta-data is stored as prop- 
erties in the interchange objects (objects which have s 
configurable properties inherited from a base class that 
provides the configurable property behavior). A property 
provides a name, a data type, default value, and rules 
for allowable values. Configuration tool 1506 performs 
automatic version management when revising (or orig- io 
inally configuring) versions of participating applications. 
When upgrading to a different version of a participating 
application, the configuration tool will determine if any 
other components are required or if alternative action 
has to be performed. '5 

Management interlaces 1508 are also meta-data 
driven. The meta-data populates a standard interlace 
such as SMS or SNMP. Standard system management 
tools are used to access those interfaces. There are two 
kinds of administrative interfaces: resource administra- 20 
tion (which servers are up, show me the threads, show 
me memory utilization, tell me when the log is x% full, 
etc.) and integration operation administration. The 
former are provided through the support of standard ad- 
ministration framework hooks. 2S 

Development Tools 

Referring now to Figure 16, development tools 60 
(Figure 3) include a connector development kit 1 600 that 30 
enables customers and vendors to build their own con- 
nectors. This will be particularly useful for customers 
who wish to integrate home-grown applications with the 
interchange. The connector development kit includes in- 
terchange protocols and API's 1 602, a connector frame- 35 
work I604(which would provide a set of classes in the 
form of source code), a packager for packaging the con- 
nector as a component 1606 and rules and data trans- 
formation tools 1608. 

40 

Bill by Call Collaboration 

A practical example of a collaboration is a "bill-by- 
call" application collaboration module where a call track- 
ing (customer support) application, upon completion of 45 
the call, sends a request to a billing application to gen- 
erate and send an invoice to the customer. The business 
process interactions between the call tracking applica- 
tion and the billing application are through a bi-direction- 
al exchange of messages. For the call tracking applica- so 
lion, the data required is the Customer ID, Name, Ad- 
dress and Billing Rate. The business functionality de- 
sired consists of CalcCallDuration (to calculate Call Du- 
ration) and tellNameAddressid (to get the Callers Name, 
Address and Customer ID) from the call tracking appli- 55 
cation. 

The data required for the billing application is Cus- 
tomer ID. Billing Address, etc. The business functional- 



ity desired are VerifyCustDetails (to determine if this is 
a valid customer) and Geninvoice (to generate and send 
the invoice to the customer). The message flows asso- 
ciated with this type of collaboration are shown in Figure 
10. 

Although simple at one I vel, the above application 
collaboration module can actually be quite complex un- 
der diverse conditions such as (a) when the Customer 
IDs in the two applications are not similar or (b) when 
the billing rate may be provided by either the call tracking 
application, the billing application or the application col- 
laboration module itself. 

Using the configuration tool, the user may set more 
specific options, such as: how to round the call duration; 
or to specify if it is a fixed charge per call or charged per 
minute; whether calls are billed individually or lumped 
together; to determine if the caller gets a certain amount 
of support free; and to identify who provides the rate of 
billing (one of the applications, the application collabo- 
ration module or if it is derived from somewhere else). 

The installation and configuration process sets 
properties on interchange server's objects and adds 
those entries to the repository. The repository also main- 
tains information on the existence and location of the 
two connectors and the application collaboration mod- 
ule. When the interchange server boots, it contacts the 
repository and finds out what components it's supposed 
to start up. In this case, it would be the two connectors 
and the one collaboration. The boot process would start 
up these components and then exits. When a compo- 
nent starts up, it consults its properties to determine its 
startup parameters. In the case of the connectors, the 
parameters would include the network location of the 
applications to be connected to, and information about 
how those applications were customized. In the case of 
the collaboration, the startup properties include things 
like which connector to use, when to instantiate the ap- 
plication collaboration object (start-up or on-request), 
etc. Note that the identity of the connector is specified 
as a name in a registry in order to preserve location 
transparency. Similarly application collaboration objects 
will have a name in the registry in order to let other in- 
terchange server's access that object directly. 

The call tracking application connector presents an 
object-and-event oriented interface to the interchange. 
For the sake of this example, imagine that the objects 
are Product, Customer, Case, and Call. Events might 
be NewCase, CallCompleted, and CaseClosed. An ex- 
ample of one of the methods supported by the call track- 
ing connector would be ReturnCaseHistory which re- 
turns information on all calls and on the duration of each 
for any given case. 

Similarly, the billing connector provides a billing ob- 
ject which exposes the accountsReceivables, and bil- 
lAccount methods. Note, that we have separated out the 
accountsReceivables method in order to maximize flex- 
ibility. This method updates the invoice information in 
the accounts receivable system. In most cases custom- 
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ers will want to control which bills are automatically in- 
serted into accounts receivable. Providing accountsRe- 
ceivable as a separate method simplifies the need to 
make the automatic insertion of bills into accounts re- 
ceivable user controllable. In cases where the bill is to 
be inserted, the method ts invoked In cases where the 
insertion should not be performed, the method is not 
used. 

When the interchange server boots up, it first in- 
stantiates all connectors, followed by all application col- 
laboration objects. At instantiation, the billing applica- 
tion's connector subscribes to the call tracking connec- 
tor's CaseClosed event (assuming that the system is not 
supposed to generate a bill until the case is closed). The 
call tracking connector generates a CaseClosed event 
when the support analyst closes the case by setting the 
status of the case to CLOSED Upon receiving the 
CaseClosed event, the collaboration object queries the 
call tracking connector for all the calls for that case and 
their duration by invoking the ReturnCaseHistory meth- 
od on the case number in question The returned call 
duration is converted into a dollar amount according to 
the business rules specified by the application collabo- 
ration object's properties. It might also have to query the 
call tracking connector to translate Customer ID to a 
customer name or it may have to map the Customer ID 
in the call tracking application to the Customer ID in the 
billing application. 

The collaboration object then invokes the billAc- 
count function for the billing object in the billing connec- 
tor, passing it the customer name, the dollar amount, 
and a text string describing the calls and the case. Suc- 
cessfully generating the bill will probably require multiple 
data conversions. Translating the customer's name into 
the Financial system's Customer ID might be necessary 
and there may be currency localization issues to ad- 
dress with regards to the representation of the dollar 
amount. Since these conversions need to be addressed 
prior to the actual submission of the billing information 
into the accounts receivable application, the collabora- 
tion object needs to be able to handle conditional data 
conversions, based on a pre-determined set of dynam- 
ically determined business rules. 

Once all data translation steps have been proc- 
essed, the collaboration can invoke the accountReceiv- 
ables function in the billing connector to update the "just 
billed" amount to the accounts receivable. 

The present invention has been described in terms 
of specific embodiments, which are illustrative of the in- 
v ntion and are not to be construed as limiting. Other 
embodiments are within the scope of the following 
claims. 



Claims 

1. A modular application collaborator for providing in- 
ter-operability between applications comprising; 



a plurality of connectors for communicating with 
a like plurality of applications: 
an interchange server including an application 
collaboration module and service module, the 

5 service module transferring messages be- 

tween connectors and the application collabo- 
ration module, the application collaboration 
module defining the inter-operabiiity between 
two or more applications, the application col- 

io laboration module including a trigger and a 

transaction responsive to the trigger, the trigger 
being activated upon receipt of data from one 
or more connectors, and the transaction deliv- 
ering data to one pr more connectors for trans- 

is fer to an associated application. 

2. The apparatus of claim 1 wherein the interchange 
server service module includes a transaction serv- 
ice and an error service, the transaction in the ap- 

20 plication collaboration module including- one or 
more actions, the transaction service for recording 
each action and a compensating action, the com- 
pensating action for undoing the associated action, 
the error service monitoring lor errors in the int r- 

25 change server and upon detection of an error stop- 
ping the execution of a transaction and triggering 
the execution of any required compensating actions 
to undo the interrupted transaction. 

30 3. The apparatus of claim 1 wherein each connector 
includes an application interface, a business mod- 
ule and interchange server interface, the applica- 
tion interface including an API manipulator for re- 
ceiving and transferring data and methods between 

35 a connector and its associated application, the busi- 
ness module including business methods and 
translorms for manipulating data for transfer be- 
tween an associated application and an application 
collaboration module, and the interchange server 

40 interface for transferring data and methods be- 
tween a connector and an application collaboration 
module. 

4. The apparatus of claim 1 wherein a transaction in- 
45 eludes a finite state machine. 

5. The apparatus of claim 1 wherein data transfers be- 
tween connectors and an application collaboration 
module are by objects transferred by the service 

50 module in the interchange server. 

6. The apparatus of claim t wherein the service mod- 
ule includes an vent servic having subscription 
and publication services and where an application 

55 collaboration module subscrib s to one or more 
connectors based on th trigger, such connectors 
publishing data to the event service upon receipt of 
trigger data from its associated application, and the 
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publication service delivering the data to the appli- 
cation collaboration module. 

7. The apparatus of claim 1 wherein the interchange 
server further includes RAS services and messag- 
ing services for assuring delivery of messages to 
interchange server components. 

8. A modular application collaborator for collaborating 
applications implementing distinct functions com- 
prising: 

an interchange server including an application 
collaboration module and service module; 
first and second application connectors, each 
connector communicating with an associated 
application and providing data transfer data be- 
tween the interchange server and the associat- 
ed application; and 

the service module transferring objects be- 
tween the first and second connectors and the 
application collaboration module, the applica- 
tion collaboration module defining the interop- 
erability between the first and second applica- 
tions, the application collaboration module in- 
cluding a trigger and a transaction responsive 
to the trigger, the trigger being activated upon 
receipt of data from a first one of the first and 
second connectors, and the transaction deliv- 
ering data to a second one of the first and sec- 
ond connectors for transfer to an associated 
application. 

9. The apparatus of claim 8 wherein the interchange 
server services includes a transaction service and 
an error service, the transaction in the application 
collaboration module including one or more actions, 
the transaction service for recording each action 
and an associated compensating action, the com- 
pensating action for undoing an action, the error 
service monitoring for errors in the interchange 
server and upon detection of an error stopping the 
execution of a transaction and triggering the execu- 
tion of any required compensating actions to undo 
the interrupted transaction. 

10. The apparatus of claim 8 wherein each connector 
includes an application interface, a business mod- 
ule and interchange server interlace, the applica- 
tion interface including an API manipulator for re- 
ceiving and transferring data and methods between 
a connector and its associated application, the busi- 
ness module including business methods and 
transforms for manipulating data for transfer be- 
tween an associated application and an application 
collaboration module, and the interchange server 
interface for transferring data and methods be- 
tween a connector and an application collaboration 



module. 

11. The apparatus of claim 8 wherein a transaction in- 
cludes a finite slate machine. 

s 

12. The apparatus of claim 8 wherein data transfers be- 
tween connectors and an application collaboration 
module are by objects transferred by services in the 
interchange server. 

70 

13. The apparatus of claim 8 wherein the service mod- 
ule includes an event service having subscription 
and publication services and where an application 
collaboration module subscribes to one or more 

'5 connectors based on the trigger, such connectors 
publishing data to the event service upon receipt of 
trigger data from its associated application, and the 
publication service delivering the data to the appli- 
cation collaboration module. 

20 

14. The apparatus of claim 8 wherein the interchange 
server further includes RAS services and messag- 
ing services for assuring delivery of messages to 
interchange server components. 

25 

15. A method for providing inter-operability between 
applications operating on different processes com- 
prising: 

30 defining an inter-operability function between a 

first and a second application; 
dividing the inter-operability function into ge- 
neric and vendor specific sub-pieces: 
creating a generic application collaboration 

35 module for storing and executing the generic 

sub-piece of the inter-operability function; 
creating two application specific connectors for 
storing and executing the vendor specific sub- 
pieces of the inter-operability function associ- 

40 ated with the first and the second applications; 

and 

linking the generic application collaboration 
module and two application specific connectors 
to achieve the inter-operability function. 
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